<html>
<head><meta charset="utf-8"><title>design meeting 2021-05-26 · t-lang · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/index.html">t-lang</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/design.20meeting.202021-05-26.html">design meeting 2021-05-26</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="240357115"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/design%20meeting%202021-05-26/near/240357115" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/design.20meeting.202021-05-26.html#240357115">(May 26 2021 at 17:02)</a>:</h4>
<p>Hey <span class="user-group-mention" data-user-group-id="1977">@T-lang</span> -- design meeting today!</p>



<a name="240357202"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/design%20meeting%202021-05-26/near/240357202" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/design.20meeting.202021-05-26.html#240357202">(May 26 2021 at 17:02)</a>:</h4>
<p><a href="https://hackmd.io/BdumkOYnRfOq0IGxOJKcDw">Document</a></p>



<a name="240377163"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/design%20meeting%202021-05-26/near/240377163" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Daniel Henry-Mantilla <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/design.20meeting.202021-05-26.html#240377163">(May 26 2021 at 19:22)</a>:</h4>
<p>A personal musing about Rust goals: obviously the main priority of implementing features is to <em>eventually</em> reach a "good" / satisfactory design, and that's when something may be eligible for stabilization. Emphasis on <em>eventually</em>: there are some things that could technically be usable right now, but which are not candidate for stabilization in order to keep the option, future-wise, to improve or change stuff.</p>
<p>I am saying all this with two main examples in mind: <code>&amp;raw</code> references, and <code>Fn…</code> traits. There is no desire to stabilize either, because of syntactical questions regarding <code>&amp;raw</code>, and <code>extern "rust-call"</code> / variadic generics questions regarding the latter, which, when one thinks about it, is a form of "syntactical" question (what to write to <code>impl Fn…</code>, what to write to refer to elements of this <code>impl</code> (<em>e.g.</em>, <code>Output</code> assoc type, <code>.call{,_mut,_one}</code> methods). All this is completely legitimate and a good thing. But as <code>&amp;raw</code> references have shown, there is a possibility for something a bit better than just "eventually being featured": <strong>intermediate tools, that could, eventually, be deprecated, but which allow for a way earlier stabilization</strong> such as <code>ptr::raw_{const,mut}!</code> (there is also another approach which I won't mention in this post, but which, ihmo, has been very successful so far: reducing unstable features to a stabilizable subset: <em>c.f.</em>, the family of <code>min_…</code> features).</p>
<p>My question then is:</p>
<blockquote>
<p>was <code>ptr::raw_…!</code> an exception, or would it be possible for other expected-to-remain-unstable-for-a-long-time features to benefit from a proxy / fronted that would allow earlier stabilization by hiding the true syntax / semantics?</p>
</blockquote>
<ul>
<li>
<p>In the case of <code>Fn…</code> traits, we could imagine a special module exporting the current definition of <code>Fn…</code> traits but without the unstable <code>rust-call</code>, and with an either "magical" forwarding / blanket impl to connect to the true <code>Fn…</code> traits, or with a finite set (<em>e.g.</em>, capped arity) of such forwarding / blanket impls.</p>
</li>
<li>
<p>Or, if we focus on just implementing these traits, we could imagine a helper macro that would give all freedom to the syntax being used to do so.</p>
</li>
<li>
<p>That being said, I do not wish to discuss the technicalities of each approach (we can use another thread or IRLO for that) for this specific example, but rather, <strong>if the idea / approach, as a whole, could be envisioned to begin with.</strong></p>
</li>
</ul>
<p>I personally consider that such approaches ought to be taken. Back to the <code>Fn…</code> trait example, I do find Rust to be quite lacking, feature-wise, on stable Rust, because of it:</p>
<ul>
<li>
<p>No access to the <code>Output</code> associated type, so HRTB expressivity is <em>very severly hindered</em> because of that (<em>sometimes</em>, helper traits can alleviate the situation, but not always), or similarly, it is not possible to bound a closure based on its input args alone, if we wish to keep higher-order signatures (<em>i.e.</em>, <code>F : FnOnce&lt;(&amp;Foo,)&gt;</code> kind of bounds). Higher-order bounds on closures are paramount for <code>async</code> closures, as well as some more advanced CPS patterns that wish to remain ergonomic (granted, most of these things are currently unusable even on <code>nightly</code> because of lazy normalization bugs, but that's besides the point here).</p>
</li>
<li>
<p>The <code>Fn…</code> trait sugar heuristics are not full-proof: writing a closure with a (lifetime-)generic return type requires funnelling it through a helper function, and closures that "yield" a borrow to a capture they <em>own</em> are not supported by the sugar either (<a href="https://internals.rust-lang.org/t/closures-that-can-return-references-to-captured-variables/14756/5?u=dhm">https://internals.rust-lang.org/t/closures-that-can-return-references-to-captured-variables/14756/5?u=dhm</a>)</p>
</li>
<li>
<p>No user-made impls of the <code>Fn…</code> traits, which lead to things like <a href="https://github.com/nagisa/rust_libloading/issues/13#issuecomment-219105072">https://github.com/nagisa/rust_libloading/issues/13#issuecomment-219105072</a>, a <em>very</em> pervasive crate featuring an unsound API that goes against the principles of safety first of the language, since fixing it without user-made impls of the <code>Fn…</code> traits would come with an ergonomic cost deemed too high.</p>
</li>
</ul>
<p>This last example is interesting: <code>Fn…</code> traits, as we know, is just sugar:</p>
<ul>
<li>
<p>the <code>()</code> call sugar, to call one of the three <code>.call…</code> methods</p>
</li>
<li>
<p>and the <code>[move] |…| …</code> sugar to generate an ad-hoc implementor of the traits with auto-generated captures and sugar to refer to these captures.</p>
</li>
</ul>
<p>So <code>Fn…</code> traits will never be <em>mandatory</em> for the expressibility of the language –they're just very simple traits after all– but they are direly needed for ergonomics, and with bad ergonomics, programs (and languages themselves!) eventually end up taking the equivalent shorter paths, even when those may not be as correct as the unergonomic one. Macros allow to replace such an arbitrarily big ergonomic hit, with a fixed-size one, but one which is still non-empty.</p>
<hr>
<p>So the way I see it, the objectives of "correctness first", "fill niches efficiently" ("niches" such as <code>async</code> closures, ergonomic CPS style, libloading…) and "productive / accessible" (directly linked to ergonomics) cannot be truly met, mid-term, without efforts for "earlier stabilization", even if such efforts were to originate from <em>de facto</em> deprecated helper modules to discourage too widespread of a usage. /endof<del>musing</del>rant <span aria-label="upside down" class="emoji emoji-1f643" role="img" title="upside down">:upside_down:</span></p>



<a name="240379857"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/design%20meeting%202021-05-26/near/240379857" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/design.20meeting.202021-05-26.html#240379857">(May 26 2021 at 19:42)</a>:</h4>
<blockquote>
<p>was <code>ptr::raw_…!</code> an exception</p>
</blockquote>
<p>no, there is a history of prototyping via a macro and making it a language feature later: see <code>try!</code> and <code>await!</code> (though the latter wasn't ever stable)</p>



<a name="240437505"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/design%20meeting%202021-05-26/near/240437505" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Dirkjan Ochtman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/design.20meeting.202021-05-26.html#240437505">(May 27 2021 at 09:03)</a>:</h4>
<p>I've been thinking lately that the incidence of <code>Panics</code> in method doc strings doesn't seem to align all that well with other Rust principles</p>



<a name="240437589"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/design%20meeting%202021-05-26/near/240437589" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Dirkjan Ochtman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/design.20meeting.202021-05-26.html#240437589">(May 27 2021 at 09:04)</a>:</h4>
<p>that is, while we try to express many of these things in the type system, too many important methods in core/std can panic (I'm thinking mostly of slice and <code>Vec</code> for now, but I think this might generalize?)</p>



<a name="240437692"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/design%20meeting%202021-05-26/near/240437692" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Dirkjan Ochtman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/design.20meeting.202021-05-26.html#240437692">(May 27 2021 at 09:04)</a>:</h4>
<p>feels to me like <code>Option</code>/<code>Result</code> cause a small enough ergonomic hit that we should opt for those instead of panics more often</p>



<a name="240499087"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/design%20meeting%202021-05-26/near/240499087" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/design.20meeting.202021-05-26.html#240499087">(May 27 2021 at 17:00)</a>:</h4>
<p>I'm not certain how much it generalizes, because <code>a[4]</code> can panic and that's part of the language.  So methods on slices and vectors that can also panic for that reason (<code>split_at_mut</code>, for example) seems completely in-line with that.</p>
<p>And even outside of indexes, I'm not convinced that, say, requiring that everyone do <code>.step_by(2).unwrap()</code> in iterator chains instead of <code>.step_by(2)</code> is a win.</p>
<p>Tooling to help avoid panics would be great.  But I don't think replacing <code># Panics</code> with <code>.unwrap()</code> is always better.  (At least for the kind of "trivial preconditions" that the library tends to use <code># Panics</code> for.  It overall does a good job of not forcing unpredictable panics on you, in my experience.)</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>